home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940121.txt < prev    next >
Internet Message Format  |  1994-11-13  |  11KB
  1. Date: Fri, 17 Jun 94 04:30:02 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #121
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Fri, 17 Jun 94       Volume 94 : Issue  121
  11.  
  12. Today's Topics:
  13.                       Calling John Ackerman AG9V
  14.           Standard Digital Radio Interface Proposal (4 msgs)
  15.  
  16. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  17. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  18. Problems you can't solve otherwise to brian@ucsd.edu.
  19.  
  20. Archives of past issues of the TCP-Group Digest are available
  21. (by FTP only) from UCSD.Edu in directory "mailarchives".
  22.  
  23. We trust that readers are intelligent enough to realize that all text
  24. herein consists of personal comments and does not represent the official
  25. policies or positions of any party.  Your mileage may vary.  So there.
  26. ----------------------------------------------------------------------
  27.  
  28. Date: Thu, 16 Jun 1994 22:27:23 -0500 (CDT)
  29. From: Kurt Freiberger <kurt@cs.tamu.edu>
  30. Subject: Calling John Ackerman AG9V
  31. To: tcp-group@ucsd.edu (TCP-Group Mailing List)
  32.  
  33. John, please send me your email address.  I have some radio questions
  34. for you.
  35.  
  36. We now return you to the scheduled pogrom...
  37.  
  38. kf
  39.  
  40. -- 
  41. # Kurt Freiberger, WB5BBW   Dept. of Computer Science, TAMU              #
  42. # Internet: kurt@cs.tamu.edu      |  "Even MY hypocrisy has its limits." #
  43. # AuralNet: 409/847-8607          |                                      #
  44. # AMPRNet: wb5bbw@wb5bbw.ampr.org |        - "Doc" Holliday, Tombstone   #
  45. # Disclaimer: Not EVEN an official document of Texas A&M University      #
  46.  
  47. ------------------------------
  48.  
  49. Date: Thu, 16 Jun 94 13:16:35 +0100
  50. From: agodwin@acorn.co.uk (Adrian Godwin)
  51. Subject: Standard Digital Radio Interface Proposal
  52. To: net_sig@tcet.unt.edu, tcp-group@UCSD.EDU
  53.  
  54. > 
  55. > A Proposal for a Standard Digital Radio Interface
  56. >
  57. > (stuff deleted)
  58. > 
  59. > Requirements
  60. > 
  61. > The requirements of the interface are as follows:
  62. >  - connect any DR to any TNC;
  63. >  - be transparent to the data stream;
  64. >  - operate over a wide range of speeds;
  65. >  - operate with both synchronous and asynchronous modulation modes;
  66. >  - operate in both full- and half-duplex modes as well as in transmit-
  67. >    only and receive-only systems;
  68. >  - provide good immunity to electromagnetic interference (EMI);
  69. >  - be tolerant of variations in the equipment: not require any 
  70. >    adjustments when equipment is changed;
  71. >  - operate over cable distances from zero to at least 10 meters;
  72. >  - be usable for all existing digital communications modes and for all 
  73. >    anticipated modes in the future;
  74. >  - operate at all existing speeds and at all reasonable future speeds, 
  75. >    at least up to 2 Mb/s;
  76. >  - have a single standardized connector so that connection is "plug and 
  77. >    play;"
  78. >  - sense when cable is disconnected or when the DR is powered down;
  79. >  - make use of existing standards, where possible; and
  80. >  - allow easy migration from the current system.
  81. > 
  82.  
  83. Seems a good start, and the presented solution addresses it well. However,
  84. the suggestion is extremely similar to that provided by a synchronous
  85. half-duplex mode (except for the differental-mode signals, which are
  86. welcome). I believe suggestions made for clock source etc. to be correct,
  87. unlike the RUH modem which requires the TNC to source a clock. 
  88. The clock edge on which data is valid (and the timing) must be specified!
  89.  
  90. However, modem interfaces have had a problem in recent years - they
  91. don't allow for an intelligent interface. The result is the Hayes and
  92. V25.bis protocols, which suffer severely from being in-band to the
  93. communications channel. 
  94. The disadvantages of this are :
  95.  
  96.   - can't control the modem/radio without interrupting the data stream
  97.   - the controller in the radio may be pretty dumb, yet have to talk
  98.     at the data rate used by the comms channel
  99.   - changeover from data to control requires extra control lines
  100.     or (worse) in-band escape sequences.
  101.  
  102. In order to avoid this problem, I'd suggest adding to the spec an optional
  103. control interface and accompanying protocol. Obvious uses for this are 
  104. channel change, carrier level measurement, power control and controlling
  105. a CW ident.
  106. I think it has to be optional to allow for present radio/modem designs,
  107. but the implementation used when no interface exists should be
  108. specified - perhaps looped back if a TXD/RXD pair is used, or shorted
  109. to ground if an IIC-like bus is used. Both the TNC and the radio should
  110. operate in a reasonable manner if the other device doesn't implement
  111. the control interface.
  112.  
  113. A clock-and-data interface is attractive for use with small microcontrollers
  114. as might typically be used in an intelligent radio-modem, since this
  115. can simplify the software implementing a software USART. IIC is a possibility,
  116. but the electrical interface is less robust than the rest of the spce
  117. and there are copyright constraints on the standard (must use a Philips-
  118. licensed component to implement part of the system).
  119.  
  120. It might be useful to ensure that the control protocol can be implemented
  121. using 'spare' parts of typical high-speed comms controllers - bit-banging
  122. I/O lines, SPI ports etc.
  123.  
  124. > 
  125. > The physical connector selected is a high-density 15-pin D-series 
  126. > connector.  This connector is small enough to be used on mobile and 
  127. > portable equipment and yet it reasonably rugged, reliable and 
  128. > inexpensive.  The male connector (plug) is used on the TNC and the 
  129. > female connector (socket) is used on the DR.  Although the same type of 
  130.  
  131. I admit to a prejudice against these connectors. Because of their high
  132. density, they tend to use formed pins rather than turned pins - I find
  133. the former less robust and inclined to bend. In addition, PCB-mount
  134. male connectors seem to be much less available than PCB-mount female
  135. connectors. This may be because many vendors only sell the parts
  136. required for PCs (female PCB connectors and male cable connectors),
  137. though there seems to be less of a problem getting cable-mount females.
  138.  
  139.  
  140. > equipment together.  It provides a simple, inexpensive, versatile, and 
  141. > easy-to-use solution.  It is applicable to all current packet radio 
  142. > systems, as well a other digital systems and it does not inhibit future 
  143. > improvements to packet radio systems, either in the modulation and 
  144. > coding techniques or in the protocols.  While the exact specifications 
  145. > remain to be finished and tested through implementation, much existing 
  146. > technology is being used and no problems are anticipated.  The author 
  147. > welcomes suggestions for the improvement of this interface and is 
  148. > interested in hearing from a few persons who are willing to design and 
  149. > test interfaces for various modems and TNCs.
  150. > 
  151.  
  152. I'd certainly benefit from a standard interface and would be happy to 
  153. work on it in my copious spare time. I think you need to present a complete,
  154. costed design - I think the manufacturers of TNCs and modems might argue
  155. with you about how inexpensive this interface is when compared to
  156. a Molex header and a few TTL signals. But it's still the right thing to
  157. aim for!
  158.  
  159. -adrian
  160.  
  161. ------------------------------
  162.  
  163. Date: Thu, 16 Jun 1994 16:31:06 -0700
  164. From: brian@nothing.ucsd.edu (Brian Kantor)
  165. Subject: Standard Digital Radio Interface Proposal
  166. To: tcp-group@ucsd.edu
  167.  
  168. I'd really recommend the use of RS-485 and RS-530 instead of once again
  169. creating our own unique-to-ham-radio incompatable-with-the-world
  170. interface.
  171.  
  172. What we're talking about here is just a radio modem.  It's no different
  173. from a wireline, optical, or other modem as far as its interface needs;
  174. we can (and SHOULD) use established standards wherever we can.  The ones
  175. mentioned above aren't even a bad fit.
  176.     - Brian
  177.  
  178. ------------------------------
  179.  
  180. Date: Thu, 16 Jun 1994 23:45:33 -0400
  181. From: "Louis A. Mamakos" <louie@alter.net>
  182. Subject: Standard Digital Radio Interface Proposal 
  183. To: tcp-group@UCSD.EDU
  184.  
  185. > I'd really recommend the use of RS-485 and RS-530 instead of once again
  186. > creating our own unique-to-ham-radio incompatable-with-the-world
  187. > interface.
  188. > 
  189. > What we're talking about here is just a radio modem.  It's no different
  190. > from a wireline, optical, or other modem as far as its interface needs;
  191. > we can (and SHOULD) use established standards wherever we can.  The ones
  192. > mentioned above aren't even a bad fit.
  193.  
  194. If we really wanted to push the state-of-the-art (Ha!), why not define
  195. the interface as ethernet, which will be plenty fast enough.  Boards
  196. for PeeCee boxes are less than $100, and you can hang a bunch of
  197. "things" on an ethernet segment.
  198.  
  199. You need only define a protocol to run over the net to carry frames of
  200. stuff between the various devices.  If you were *really* clever, you
  201. could also transport PCM audio this way too.
  202.  
  203. Clever folks could develop a small single board computer to terminate
  204. the ethernet in a device, and which contains a simple ROM-based
  205. software module to do generic sorts of things.  Hook it (or build it
  206. into) things like radios, rotator boxes, etc.
  207.  
  208. Wouldn't it be cool of the front panel of your radios was "soft", and
  209. you had a single (ethernet) coax running from the operating position,
  210. out to the antennas where the actual RF hardware is.  
  211.  
  212. Heck, if you didn't want to use ethernet because it's too "hard", look
  213. at the more expensive and slower ISDN hardware devices.
  214.  
  215. If nothing new or interesting is going to be done, just stick with
  216. RS232 and a DB9 connector.
  217.  
  218. Louis A. Mamakos, WA3YMH            louie@alter.net
  219. UUNET Technologies, Inc.            uunet!louie
  220. 3110 Fairview Park Dr., Suite 570        Voice +1 703 204 8023
  221. Falls Church, Va 22042                Fax   +1 703 204 8001
  222.  
  223. ------------------------------
  224.  
  225. Date: Fri, 17 Jun 94 00:07 EDT
  226. From: nelson@crynwr.com (Russell Nelson)
  227. Subject: Standard Digital Radio Interface Proposal
  228. To: louie@alter.net
  229.  
  230.    From: "Louis A. Mamakos" <louie@alter.net>
  231.    Date: Thu, 16 Jun 1994 23:45:33 -0400
  232.  
  233.    Clever folks could develop a small single board computer to terminate
  234.    the ethernet in a device, and which contains a simple ROM-based
  235.    software module to do generic sorts of things.  Hook it (or build it
  236.    into) things like radios, rotator boxes, etc.
  237.  
  238. Yes!  Yes!  Yes!  Sixteen bits of digital I/O, and a sixteen bit D/A
  239. and A/D would be enough for many purposes.  Or maybe a daughter board
  240. that implements the I/O?
  241.  
  242. -russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
  243. Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
  244. 11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
  245. Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
  246.  
  247. ------------------------------
  248.  
  249. End of TCP-Group Digest V94 #121
  250. ******************************
  251.